Bad rewrite again :/

nit: s/that are called/

nit: "… applied. set. You …"

nit: "… current overlay. Nixpkgs. It …"

it isn't really final though, is it? It can be overlayed on top of later.

final is the composition of all overlays, including the future ones too.

However, the brevity and clarity of final in this rr example highlights that we should use e.g. final.callPackage, not previous.callPackage for functions, and use previous only when we explicitly want the previous definition (because the current definition will shadow it in the final set).

@grahamc stdenv_32bit is the final, as this is the result which went through the fix-point.
rr is not final yet, it might be overriden, and would be in the previous set of the next overlay.

@orivej that makes sense to me. Updated PR to use final.callPackage unless @nbp disagrees and wants me to change it back.

I disagree, callPackage is a function, and it should come from previous, not final.

callPackage is a function, which it-self captures self to provide the packages to the package, and using it through self will go through the fix-point twice.

This does not make sense to me. For the interpreter the fix point is not a loop, and there is no such thing as the count of goes through the fix point. (Here is an accurate enough model of the internal states of a straightforward interpreter of the nix language that illustrates this: https://gist.github.com/orivej/5fddcf792dfa37a5bfa16d9a95fe70fa .) Using final is in no way less computationally efficient than using previous. When callPackage is not overridden in a future overlay, final.callPackage is exactly the same as previous.callPackage, but the choice of the former is more obvious.

@orivej Today there is not, but the reason the documentation is that way, is to make sure that we make the code written by user future-proof. Doing the opposite would become a problem for automatic grafting.

As you mentioned, there is no difference today, but doing it as currently mentioned in the documentation will prevent the addition of issues that would have to be fixed later.

I disagree, callPackage is a function, and it should come from previous, not final.

Could you explain why functions should come from previous? I am fairly certain that in practice this is a stylistic choice until someone wants to override some functions (and final looks better), that we should use final if they do, and it should not concern us if the referenced value is a derivation or a function . The only concern is if we can just use the final value, or if we need the previous value to implement our override of it.

@nbp Could you detail the future plans? What is automatic grafting?

From the name of it I guess the automatic grafting is deep merging of attribute sets, but that does not seem to cause any issues with using functions from final.

@orivej The automatic grafting described in #10851 , which is coming slowly, depends on the fact that we can peel off the fix-point and watch the number of hops through the fix-point. Using a function which captures self, from self, implies that we go twice through self, and miss this dependency.

nit: […] current overlay. Nixpkgs. It does […]